Making a draft temporarily, need to add comments about the unwraps. Also probably a good idea for it to be a draft until we figure out what the API should be.

I don't need gcd_vartime() for crypto-primes, it was just added for completeness sake.

Since we have Bernstein-Yang now defined on both Uint and BoxedUint (just landed in #497), perhaps it's unnecessary?

I can add a trait for computing GCD and bound Integer on it.

If you do want to include it for completeness, it'd be good to check if it's actually faster than the constant-time implementation (Bernstein-Yang is surprisingly fast), and then I'd prefer it be exposed as a provided Integer::gcd_vartime method (though the implementation could look like it does now, just pub(crate))

Since we have Bernstein-Yang now defined on both Uint and BoxedUint (just landed in #497), perhaps it's unnecessary?

But that's constant-time, correct? I'm using it in a vartime context, so running the constant time thing would lead to performance degradatation.

Let me run some benchmarks.

Actually let me roll it back. There are a few assorted considerations:

• The GCD and Jacobi symbol functions I need are somewhat specialized, and if Integer provides the required functionality, I can just keep them in crypto-primes for now. Plus I'm not exactly sure how to implement Jacobi symbol in terms of Bernstein-Yang (although I remember reading that it's possible).
• The vartime division algorithm we have is super inefficient, I want to make a separate PR for it.
• Vartime division-by-limb can be added, but that's also a separate PR (although the constant-time one is already fast enough since in my application I only need to do it once).

• Plus I'm not exactly sure how to implement Jacobi symbol in terms of Bernstein-Yang (although I remember reading that it's possible).

@fjarri just stumbled on https://www.shiftleft.org/papers/byj/byj.pdf.